Release 10.1A: OpenEdge Getting Started:
Object-oriented Programming

Strong typing

Strong typing is the enforcement of type conformance. Classes essentially define data types, which are analogous to the built-in data types of the language. Classes are identified with a type name that includes the name of the class. The name of a class matches its physical file name, which together with its type name allows Progress to locate the at both compile time and run time. With its type name, the class file also implicitly defines the class as a data type, which the compiler uses to validate references to the class.

This is similar to data type checking for variables. At compile time (for references within a single procedure) or at run time (for parameters passed between procedures), Progress verifies that a reference to a parameter matches the data type of the parameter definition. In a similar fashion, Progress uses the entire class definition, including all of its data members and methods, as a distinct type which must be perfectly matched by all references to the class. All type usage is validated at compile time ensuring that a method cannot be invoked on a class unless a method with the exact signature is defined by the class or its hierarchy. Thus, the compiler ensures that the program will execute without type errors. Again, this is similar to Progress ensuring that you do not attempt to multiply two character strings by each other, because only numeric data types can be multiplied.

Comparison with procedure-based programming

Strong typing is one of the key differences between procedure-based and class-based programming. When one Progress procedure runs another, Progress is generally unable to tell at compile time whether the RUN statement is valid or not. Even when you run an internal procedure in the same procedure, Progress does not verify that the internal procedure exists or that its signature matches. If you run another external procedure, or an internal procedure that is contained in another external procedure, the compiler has no way of checking whether the RUN statement is valid because the compiler never examines one procedure while it is compiling another.

When you use classes, because of strong typing, the compiler always verifies the correctness of every statement that references another class, and might even compile the other class to do this, depending on the relationship between the classes. This compile-time validation across classes is one of the most fundamental benefits of using classes. Procedure-based programming gives you greater flexibility in how the pieces of your application fit together, even allowing you to specify the name of a procedure as a variable or expression. But this flexibility comes at the cost of much less confidence at compile time that all the elements of your application will operate and interact correctly when you run it. Thus, class-based programming provides the opportunity to move much more of the verification of an application's correctness from the burden of run-time testing into the compiler.